An Ethernet PON (EPON) is currently using 1 gigabit per second transport, which is suitable for very high-speed data applications, as well as for converged system support (telephone, video, etc.). The unprecedented amount of bandwidth is directed toward, and arriving from a single entity, the Optical Network Unit (ONU).
FIG. 1 shows a PON 100 that facilitates the transmission of data between an Optical Line Terminal (OLT) 102 and a plurality of ONUs. An ONU may include a single entity, e.g. ONUs 104 (A) and 106 (C), or an unlimited number of entities, e.g. ONUs 108 (B) and 110 (D). An entity inside an ONU may be a single user, a bundle of users as for example in a Multi Dwelling Unit (MDU) application, or a service, such as voice, video and data in a converged system. An OLT downlink transmission passes through passive optical splitters 112a-c and reaches all ONUs. An GNU uplink transmission passes through all the passive optical splitters located between the respective ONU and the OLT. For example, an uplink transmission between ONU 106 and OLT 102 passes through passive optical splitters 112b and 112a. Due to the physical properties of a passive optical splitter, only the OLT can receive the transmission from the ONU, while the other ONUs receive attenuated reflections. The uplink transmission employs time division multiplexing (TDM) to arbitrate between different entities transmitting at different times.
The existing IEEE 802.3 specification, which is incorporated herein by reference, defines a registration process, shown schematically in FIG. 2. The process as defined therein can handle only a single entity per ONU. An OLT transmits a registration GATE message dedicated for ONUs wishing to register. Unregistered ONUs respond with a register request (REGISTER_REQ) message. The REGISTER_REQ message includes a flags field, which acts as an operation code (opcode), as it determines the operations requested by this message. Several ONUs might attempt to register simultaneously. The transmissions might collide in what is marked as a “contention zone”. The OLT continues the process by transmitting a REGISTER command and a second, regular GATE message. The second GATE message allows an ONU to answer with a register acknowledge (REGISTER_ACK) message.
An access network should enable provisioning, policing and accounting of each client. In applications where several users connect to a single switch, the contribution of each of a plurality of different user sources to the combined traffic cannot be distinguished. In an EPON application, which follows a request-grant based protocol, the service provider wishes to configure an OLT to control the quality of service (QoS) of the uplink traffic per user. The concept of QoS is well known, and described for example in for Asynchronous Transfer Machine (ATM) based systems in the ITU G.983.4 specification, which is incorporated herein by reference. In addition, any independent decisions made by an ONU that may cause degradation of performance and lead to an unstable scheduling algorithm, may confuse the OLT, which does not expect such independent decisions.
A simple existing solution to the data-handling problem is shown in FIG. 3a. The figure describes the behavior of a bridgeless ONU having a plurality of registered entities. The solution involves two processes. The process shown on the left (steps 300 till 308) describes the actions taken when a packet is received from an OLT. The process shown on the right (steps 310 and 312) describes the actions taken when a packet is received from one of a plurality of user ports. This solution does not use a bridge, and the traffic direction decision is based on multiplexing/demultiplexing (mux/demux).
The left process begins when a packet is received at step 300. In a comparison step 302, the packet preamble is compared with all the Logical Link Identifications (LLIDs) registered for this ONU, the LLIDs serving for path identification. That is, the packet is identified as directed to one of the user ports, or as “broadcast” i.e. directed to all ports. If a user port destination LLID is found but the broadcast bit is not set, the packet is directed to the user port associated with the LLID in step 304. If a user port destination LLID is found but the broadcast bit is set, the traffic is directed to all ports except the one that was found associated with the LLID in step 306. If the LLID is identified in step 302 as a “broadcast” LLID, then the packet is directed to all registered user ports in step 308. A packet received from any user port is handled at step 310. The packet is always transmitted to the OLT in step 312.
A major disadvantage of this solution is the fact that when two users want to communicate, the traffic has to go up to the OLT and then be reflected down. This increases the uplink traffic and decreases the network utilization, as it leads to upstream-downstream traffic collisions.
Another simple existing solution to the data-handling problem is shown in FIG. 3b. The figure describes the behavior of an ONU with a single registered entity, the ONU having a bridge. The bridge behavior is compliant with the IEEE 802.1D specification, which is incorporated herein by reference. This solution also involves two processes. The process shown on the left (steps 350 to 360) describes the actions taken by the ONU when a packet is received from an OLT. The process shown on the right (steps 362 to 370) describes the actions taken by the ONU when a packet is received from one of a plurality of user ports.
In the left process, a packet is received from the OLT in step 350. The packet preamble is compared with the LLID registered for this ONU in step 352, to check if the packet's destination is the specific ONU. If a match is found, the process continues with a Source Address (SA) learning step 354, in which the SA of the packet is learned and stored in a database as described in section 7.8 of the IEEE 802.1D specification. In a Destination Address (DA) search step 356, the DA of the packet is searched by the OLT inside the SA storage database mentioned above. If the search result is positive, and the DA is found in a database associated with one of the user ports, the data is transmitted specifically toward that port in step 360. Otherwise, the packet is transmitted to all user ports in step 358.
In the right process, a packet is received from one of the user ports in step 362. In step 364, the Source Address (SA) of the packet is learned from a user port and stored according to the IEEE802.1D specification, as mentioned above. This is followed by a DA search step 366 similar to step 356. If the search result is “negative” (no DA found), or the address is “broadcast”, a command to transmit the packet to the OLT and to all user ports except the originating one is issued in step 372. If the search result is “positive” in the sense that the DA is learned from the OLT, the packet is transmitted only to the OLT in step 370. If the DA is learned from a user port that is not the originating port, the packet is transmitted toward that port in step 368.
The major drawbacks of this solution are the lack of ability on the part of the OLT to control the uplink bandwidth of each user, and the requirement to learn all OLT source addresses, which requires expensive memory storage.
Therefore, it is desirable to provide a segregation of traffic to several customers or services in an EPON, in which each customer or service can be handled separately, enabling finer management and bandwidth control. It is also highly desirable that the OLT control the ONU scheduling policing, allowing better control to the service provider, and avoiding the need for the user to configure correctly the queuing policy.